Security of mobile terminals, such as portable communication devices (PCDs) (e.g., cellular telephones), portable digital assistants (PDAs), laptop computers, or any suitable device that is capable of communicating with a wireless network, is increasingly important to mobile terminal users. Security algorithms are often employed to achieve security between a mobile terminal and another network entity. These security algorithms often rely upon a secret that is shared between the mobile terminal and the other network entity that permits the mobile terminal to be authenticated. Typically, this shared secret is embodied in the form of a key. In order to further enhance the security, many security algorithms require re-keying at various intervals. Re-keying is a process in which new keys are established such that future communications may be protected with the new keys. If a third party obtained one set of keys and therefore compromised the security between the mobile terminal and the other network entity, re-keying would prevent the third party from continuing to be able to access the communication with the mobile terminal once a new set of keys has been established, thereby limiting temporally the security breach.
An example of client authentication for which secure communication is highly desirable is HTTP digest access authentication. HTTP digest access authentication verifies that both a client and a server know a shared secret (HTTP password). In HTTP digest access authentication, it is desirable that the verification be performed without sending the password in the clear, i.e., in an unprotected manner. Following performance of the verification, secure communications are commenced between the client and the server.
The HTTP digest access authentication scheme is based on a simple challenge-response paradigm. The scheme involves a challenge being issued to the client using a nonce value. A valid HTTP response to the challenge verifies knowledge of the shared secret. An HTTP response is generated as an output from a security algorithm or security function. The output contains a checksum of the username, the HTTP password, the nonce value, the HTTP method, the requested universal resource indicator (URI), and possibly other information (such as the payload). Accordingly, if the HTTP password can be obtained by another entity, security is lost with respect to subsequent communications.
A mobile terminal typically includes at least a user identity module (UIM) and mobile equipment (ME). The UIM is a low power processor that contains secure memory and provides secure processing. The UIM may be, for example, a universal integrated circuit card (UICC), a subscriber identity module (SIM), a removable user identity module (R-UIM), etc. Thus, the UIM may be a removable device or embedded in the mobile terminal. The ME contains a high power processor and is not assumed to contain secure memory or provide secure processing.
For mobile applications, an HTTP client either runs inside the UIM or at the ME. It is more desirable to run an HTTP client in the ME due to the high processing power of the ME. In this case, the HTTP response is either generated in the ME or delivered from the UIM to the ME. Then the HTTP response is sent from the ME to a network entity in order to perform verification of knowledge of the shared secret. The current means for accomplishing the delivery of the HTTP response to the ME requires that the HTTP password either be sent to or stored at the ME. The HTTP password may then be used to generate the HTTP response. However, since the ME may not contain secure storage and/or provide secure processing capability, the HTTP password is at risk of being compromised, thereby preventing secure communication between the HTTP client and the server.
In order to prevent the above described security risk, the HTTP response may be generated in the secure UIM. However, a digest response requires the HTTP client to use the password and optionally the entity body (HTTP payload), if integrity protection of the payload is selected (by setting qop=“auth-int” in the appropriate headers). In such cases, how the UIM obtains the payload for the computation of the digest response is lacking. In particular, the payload may be large in size, and therefore sending the payload from the ME to the UIM is not desirable.
Additionally, in order to support server authentication, the digest response from the server must be verified by the HTTP client. Such verification currently also requires sending the password to the HTTP client for authentication, thereby decreasing security.